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Foreword 


This  document  describes  a  draft  specification  for  an  architecture  for 
interactive  courseware  delivery  systems.  It  was  developed  under  the 
sponsorship  of  the  Office  of  Secretary  of  Defense  (Force  Manage¬ 
ment  and  Personnel).  The  technical  sporsor  was  Mr.  Gary  Boycan. 
Funding  was  provided  under  Program  Element  0604722J,  Work 
Unit99-PJl-90-006. 

This  document  was  developed  under  the  technical  supervision  of  Dr. 
Raye  Newmen,  Dr.  Wallace  H.  Wulfeck,  and  Mr.  Walter  F.  Thode  of 
the  Navy  Personnel  Research  and  Development  Center  (NPRDC). 
This  report  itself  was  written  by  Systems  Engineering  Associates 
under  Contract  N66001-88-D-()054,  Delivery  Order  7J30. 

This  architecture  was  developed  as  part  of  an  effort  to  complete  a 
reference  implementation  of  a  courseware  portability  specification. 
The  implementation  is  scheduled  for  later  this  year.  Comments  on 
the  architecture  described  here  are  solicited  from  all  interested  par¬ 
ties.  The  specification  will  then  be  submitted  for  consideration  for 
official  adoption  by  the  Department  of  Defense  and  the  National  In¬ 
stitute  of  Standards  and  Technology. 

Point  of  contact  at  NPRDC  is  Walter  F.  Thode  (619)  553-7703  or 
AUTOVON  553-7703. 


WALLACE  H.  WULFECK  D 
Director,  Training  Technology  Department 
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Summary _ 

Background 

Over  the  next  several  years  the  Federal  Government  will  invest  mil¬ 
lions  of  dollars  to  develop  training  materials  for  delivery  on  comput¬ 
er-based  interactive  training  systems.  To  support  this  investment, 
Federal  agencies  will  acquire  a  variety  of  computers  and  peripheral 
devices.  This  hardware  host  several  operating  systems  and  au¬ 
thoring  system  software  to  speed  courseware  development. 

Many  vendors  produce  high-performance,  low-cost  training  hard¬ 
ware,  but  bundle  their  products  with  proprietary  software  interfaces. 
Because  these  interfaces  are  proprietary,  courseware  and  authoring 
systems  written  to  operate  on  one  set  of  hardware  will  not  run  on  a 
competitor’s  hardware.  Expensive  reprogramming  is  needed  to 
adapt  to  new  hardware.  These  reprogramming  costs  can  be  eliminat¬ 
ed  by  adopting  standard  software  interfaces. 

Objectives 

The  objectives  of  this  effort  were  to  describe  and  develop  a  standard 
software  interface  that  will  allow  training  systems  to  be  assembled 
from  separate  “plug-and-play”  components  in  the  same  way  that  ste¬ 
reo  systems  can  be  assembled  from  separate  speakers,  amplifiers, 
and  other  components. 

Approach 

The  Portable  Courseware  (PORTCO)  architecture  consists  of  two 
interfaces,  the  Device  Services  Interface  and  the  Device  Handler  In¬ 
terface.  It  also  contains  three  layers;  application,  routing  and  config¬ 
uration,  and  the  device  handler.  This  architecture  should  allow 
applications  software  to  run  on  any  compliant  set  of  hardware  com¬ 
ponents. 

Results  and  Conclusions 

This  report  is  the  first  in  a  series  of  five  reports;  it  provides  an  over¬ 
view  of  the  PORTCO  architecture  and  should  be  jf  interest  to  all 
who  are  concerned  with  computer-based  training.  The  second  report 
describes  the  MS-DOS  Device  Services  Interface  and  is  intended 
primarily  for  programmers  who  want  to  develop  portable  applica¬ 
tion  software.  The  third  report  describes  the  Device  Handler  Inter¬ 
face  and  should  be  of  primary  interest  to  device  manufacturers  and 
system  vendors  who  must  develop  device  handler  software.  The 
fourth  report  is  intended  for  system  vendors  and  describes  the  design 


of  the  first  PORTCO  routing  and  configuration  program.  The  fifth  re¬ 
port  is  intended  as  additonal  support  for  those  who  must  develop 
complaint  MS-DOS  device  handlers. 

Recommendations 

1 .  The  reports  describing  the  PORTCO  architecture  should  di¬ 
rect  development  of  portable  MS-DOS  applications  and  standard  pe¬ 
ripheral  device  handlers. 

2.  The  architecture  should  serve  as  a  foundation  for  compliance 
with  the  Interactive  \^deo  Industry  Association’s  “Recommended 
Practices  for  Interactive  V^deo  Portability.”  The  architecture  should 
motivate  development  of  specific  applications  and  device  handlers 
that  adhere  to  this  specification. 

3.  Feedback  about  problems  and  suggested  improvements 
should  be  forwarded  to  the  Navy  Personnel  Research  and  Develop¬ 
ment  Center,  Code  152. 
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1.  Introduction 


Over  the  next  several  years  the  Federal  Government  will  invest  millions 
of  dollars  to  develop  training  materials  for  delivery  on  computer-btised 
interactive  training  systems.  To  support  this  investment,  F^eral 
Agencies  will  acquire  a  variety  of  computers  and  peripheral  devices.  ’  This 
hardware  will  host  MS-DOS  ^  or  UNIXs  operating  systems  and  authoring 
system  software  to  speed  courseware  development. 

Many  vendors  produce  high-performance,  low<ost  training  hardware, 
but  bundle  their  products  with  proprietary  software  interfaces.  Vendors  of 
integrated  training  systetns  bundle  their  products  with  interfaces  to  all 
system  resources,  while  vendors  of  individual  peripherals  (such  as  mice) 
bundle  their  products  with  simpler,  single-device  interfaces.  Because 
these  interfaces  are  proprietary,  courseware  and  authoring  software 
written  to  operate  on  one  product  will  not  run  on  a  competitor's  product. 
Expensive  reprogramming  is  needed  to  adapt  to  new  peripheral 
hardware.  These  reprogramming  costs  can  be  eliminated  by  adopting 
standard  software  interfaces. 

This  paper  introduces  two  standard  interfaces  that  allow  training  systems 
to  be  assembled  from  separate  "plug-and-play"  components  in  the  same 
way  that  stereo  systems  can  be  assembled  from  separate  speakers, 
amplifiers,  etc.  Named  the  Device  Services  Interface  (DSI)  and  the  Device 
Handler  Interface  (DHI),  they  are  part  of  the  Portable  Courseware  (PORTCO) 
architecture  illustrated  in  figure  1  (and  discussed  in  section  4). 

The  DSI  allows  application  authors  and  system  integrators  to  write  software 
that  controls  generic  logical  devices,  instead  of  particular  devices  from 
particular  manufacturers.  The  DHI  allows  vendors  to  write  standard 
device  handlers.  Together,  the  DSI  and  DHI  provide  a  foimdation  to  build 
sophisticated  applications  that  can  easily  adapt  to  changes  in  individual 
system  components. 


1.  Special  terms  appear  in  Holies  when  first  used,  and  are  defined  in  section  6. 

2.  MS-DOS  is  a  registered  trademark  of  Microsoft  Corporation. 

3.  UNIX  is  a  trademark  of  AT&T  Bell  Laboratories. 
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Figure  1:  A  three- 
layer  PORTCO 
architecture  mil 
enhance  portability. 


Device  Services  Interface 


Device  Handler  Interface 
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2.  Puipose  and  Scope 


This  paper  describes  the  PORTCO  architecture  and  its  two  standard 
software  interfaces,  the  E)SI  and  the  DHI.  The  PORTCO  architecture  will 
be  implemented  in  two  stages,  first  on  MS-DOS-based  platforms  and  then 
on  UNIX-based  platforms.  This  is  one  of  several  publications  guiding  the 
architecture's  M^DOS  implementation.  Section  7  lists  other  MS-DOS- 
based  PORTCO  publications.  A  similar  set  of  documents  will  be 
published  in  FY  90  depicting  the  architecture's  UNIX  implementation. 

This  paper  provides  an  overview  of  the  PORTCO  architecture;  details  are 
provided  in  other  PORTCO  publications.  This  paper  should  be  reviewed 
by  all  users,  administrators,  developers,  and  maintainers  before  reading 
the  other  publications  listed  in  section  7. 

The  following  section  introduces  logical  devices  and  device  classes,  and 
shows  how  these  concepts  can  be  applied  to  insulate  application  software 
from  changes  in  peripheral  equipment.  Section  4  presents  the  three-layer 
PORTCO  architecture.  It  describes  the  purpose  of  each  layer,  provides  an 
overview  of  the  layers'  packet-based  communication  protocols,  and 
describes  the  architecture's  two  standard  interfaces.  For  readers  who 
desire  more  information,  section  5  elaborates  upon  the  other  PORTCO 
publications  and  helps  direct  further  reading.  Section  6  presents  a 
glossary  of  special  words  used  in  this  paper. 
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3.  Preliminary  Concepts 


Peripheral  devices  from  different  vendors  frequently  share  common 
features.  But  to  distinguish  themselves  in  the  marketplace,  vendors  add 
product  features  and  protocols  that  are  slightly  different  from  their 
competitors..  Application  authors  must  create  expensive  new  software  to 
accommodate  these  similar,  yet  different,  peripheral  protocols  and 
services. 

For  example,  different  vendors  might  design  their  videodisc  players  to 
display  a  still  frame  in  respoi«e  to  different  command  strings.  Or  one 
vendor  might  provide  separate  conunands  to  present  a  video  motion 
sequence  ("Set  End  Marker,"  "Search  To  Start  Frame,"  "Play  To  End 
Marker"),  while  another  might  provide  a  single  high-level  command  to 
play  from  one  video  frame  to  another.  Accommodating  these  differences 
requires  custom  programming  for  each  player.  Such  programming  can 
be  eliminated  by  writing  software  to  control  logical  devices  instead  of 
particular  peripherals  from  particular  vendors. 


3.1  Logical  Devices  and  Device  Classes 

A  logical  device  is  a  concept  (not  a  piece  of  hardware)  that  is  synthesized 
from  characteristics  of  several  similar  peripherals.  For  example,  a  logical 
videodisc  player  might  be  synthesized  wi&  attributes  common  to  many 
actual  players:  It  may  have  a  door  to  insert  or  remove  videodiscs;  it  may 
have  a  remote  control  unit  to  usurp  computer  control;  and  it  may  respond 
to  a  fixed  collection  of  display  and  action  command  strings. 

Because  a  logical  device  is  a  concept,  not  a  piece  of  hardware,  it  is 
characterized  only  by  the  services  it  provides,  not  by  its  physical 
attributes.  A  collection  of  logical  device  services  is  called  a  device  class. 

A  device  class  is  like  a  mold  from  which  identical  logical  devices  are 
fashioned.  Just  as  a  mold  used  to  cast  an  automobile  engine  block 
precisely  defines  the  size  and  shape  of  the  block,  services  in  a  device  class 
precisely  define  the  behavior  of  a  logical  device.  For  example,  services  in 
the  videodisc  player  device  class  precisely  define  the  behavior  of  a  logical 
videodisc  player.  (All  PORTCO  device  classes  are  specified  in  references 
1  and  2). 

When  an  application  author  designs  software  to  control  a  logical  device, 
he  does  not  need  to  be  concerned  with  the  operation  of  any  particular 
vendor's  peripheral.  The  author  must  only  be  concerned  with  the 


services  provided  by  the  logical  device  (i.e.,  the  services  in  its  device 
class).  So  using  logical  devices  insulates  an  author  from  the  details  of  any 
particular  peripheral's  operation. 


3.2  Device  Handlers 


To  run  a  program  designed  for  logical  devices  on  real  hardwau-e,  part  of 
the  system  must  translate  requests  for  logical  device  service  into 
instructions  that  real  hardware  imderstands.  Software  modules  that 
perform  this  translation  are  called  device  handlers.  Figure  2  iUustrates 
the  relationship  between  a  logical  device,  a  physical  device,  and  a  device 
handler.  In  this  figure,  an  application  issues  service  requests  to  a  logical 
videodisc  player.  A  device  handler  intercepts  these  requests  and 
translates  them  into  instructions  that  a  physical  videodisc  player  can 
understand. 


Figure  2:  A  device 
handler  translates 
requests  for  logical 
device  service  into 
instructions  that  a 
physical  device  can 
understand. 


Identical  peripherals  from  the  same  manufacturer  can  be  interchanged 
without  affecting  an  application's  performance  because  they  have 
identical  hardware  and  software  interfaces.  Such  peripherals  are  like 
identical  twins,  they  "look”  the  same  to  applications.  To  plug-and-play 
peripherals  from  different  manufacturers,  these  different  peripherals 
must  also  "look"  identical  to  applications.  Standard  device  handlers  can 
make  dissimilar  peripherals  "look"  the  same. 

For  example,  because  the  application  in  figure  2  requests  service  from  a 
logical  videodisc  player,  not  from  the  physical  peripheral,  it  "sees"  only 
the  player's  standard  device  handler,  not  the  player  itself.  A  player  from 
any  other  manufacturer  can  therefore  be  substituted,  without  changing 
the  application,  by  at  the  same  time  substituting  a  different  device 
handler. 
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Figure  3: 
Applications 
request  service  from 
multiple  logical 
devices  by 
specifying  a 
device's  class  and 
number. 
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Logical  devices  and  standard  device  handlers  can  also  insulate  from 
peripheral  hardware  those  applications  that  control  two  or  more  devices. 
For  example,  figure  3  shows  a  program  that  controls  two  videodisc 
players,  one  from  manufacturer  A  and  one  from  manufacturer  B.  The 
program  requests  service  by  specifying  the  applicable  device  class 
(videodisc  player)  and  the  logical  device  from  that  class  (player  #1  or 
player  #2).  As  in  figure  2,  either  of  the  players  in  figure  3  might  be 
replaced  with  players  of  different  makes  and  models  by  changing  the 
device  handler,  not  the  application. 


33  Core  and  Extended  Services 

Use  of  logical  devices  and  standard  device  handlers  lets  applications 
request  peripheral  services  in  a  standard  way,  but  some  physical 
peripherals  may  not  support  all  services  in  their  device  class.  For 
example,  the  PORTCO  overlay  device  class  contains  a  service  to  set  a 
video  dissolve  level,  but  not  all  overlay  cards  can  effect  a  video  dissolve. 
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To  solve  this  problem,  each  PORTCO  device  class  identifies  a  subset  of 
services  that  are  common  to  all  physical  devices  in  the  class.  These  are 
called  core  services.  The  rest  are  called  extended  services,  and  may  or  may 
not  be  available  on  a  specific  physical  peripheral  in  the  class.  For 
example,  the  service  described  above  to  set  a  video  dissolve  level  would 
be  an  extended  service  (because  it  is  not  available  on  all  overlay  cards), 
while  a  service  to  make  a  color  transparent  and  opaque  would  be  a  core 
service  (because  all  overlay  cards  offer  it). 

Application  authors  can  ensure  portability  by  using  core  services.  Using 
extended  services  may  enhance  performance,  but  will  reduce  portability 
to  only  those  peripherals  that  support  the  required  extensions.  So 
extended  services  allow  application  authors  to  balance  their  products' 
portability  and  performance.  They  also  allow  vendors  to  differentiate 
themselves  in  the  marketplace  by  letting  them  choose  which  extensions  (if 
any)  their  products  will  offer. 

The  PORTCO  architecture  must  evolve  gracefully  with  advancing 
technology.  Core  service,  extended  services,  and  device  classes  provide 
a  framework  for  this  evolution.  Extended  services  will  be  added 
frequently  as  manufacturers  create  new  hardware  features.  These  will 
become  core  services  as  they  are  adopted  by  a  larger  segment  of  the 
peripheral  marketplace.  New  device  classes  will  be  added  with 
significant  breakthroughs  in  peripheral  technology  (e.g.,  digital  video 
interactive). 


3.4  Requests  and  Alerts 

Applications  must  be  able  to  request  services  from  logical  devices,  and 
they  must  be  alerted  asynchronously  when  important  device  activity 
occurs.  For  example,  an  application  should  be  able  to  ask  a  videodisc 
player  to  show  a  still  frame,  and  it  should  be  alerted  when  a  mouse 
movement  or  button-press  occurs.  Two  types  of  services  are  included  in 
each  PORTCO  device  class  to  satisfy  this  requirement.  Requests  are  used 
to  solicit  service,  and  alerts  are  used  to  inform  applications  of 
asynchronous  device  activity.  All  requests  and  alerts  are  specified  in 
references  1  and  2. 
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4.  PORTCO  Architecture 


The  PORTCO  architecture  contains  three  layers  and  two  standard 
interfaces,  illustrated  in  figure  1  (page  2).  Each  layer  communicates  with 
its  neighbor(s)  using  contiguous  blocks  of  data  called  packets.  For 
example,  applications  request  peripheral  service  by  passing  packets 
through  the  routing  and  configuration  layer  {R6rC  layer)  to  device  handlers. 
Figure  4  illustrates  packet  routing  for  PORTCO  requests  and  alerts. 


Figure  4:  Routing 
of  request  and  alert 
packets  is  almost 
identical. 


Requests 


till 


Alerts 
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Standard  device  handlers  constitute  the  lowest  layer  of  the  PORTCO 
architecture.  They  translate  requests  for  logical  device  service  into 
instructions  that  real  peripherals  can  understand.  They  also  alert  the 
architecture's  upper  layers  when  device  activity  (e.g.,  a  mouse  movement) 
occurs.  As  discussed  in  section  3.2,  device  handlers  are  the  only  PORTCO 
components  that  depend  upon  physical  devices;  they  are  the  orJy 
components  that  must  be  replaced  when  peripheral  devices  are  changed. 
Device  handlers  are  implemented  as  modified  MS-DOS  executable  files. 

The  middle  layer  of  the  PORTCO  architecture  is  called  the  R&C  layer.  It 
loads  and  configures  device  handlers  and  routes  packets  between 
applications  and  device  handlers.  For  example,  in  the  system  illustrated 
by  figure  3  (page  6),  the  R&C  layer  would  direct  all  packets  requesting 
service  from  logical  videodisc  player  #2  to  videodisc  player  A's  device 
handler  (instead  of  videodisc  player  B’s).  The  R&C  layer  is  implemented 
as  a  TSR  program. 

Application  software  constitutes  the  PORTCO  architecture's  highest 
partition.  This  layer  also  contains  the  DSI  toolbox.  This  is  a  collection  of 
software  modules  (developed  by  the  PORTCO  user  community)  that 
helps  applications  use  the  DSI.  In  the  simplest  case,  the  toolbox  consists 
of  :^nctions  in  various  progranuning  languages  that  format  packets  and 
pass  them  to  the  R&C  layer  (i.e.,  language  bindings).  More  sophisticated 
toolbox  components  might  coordinate  the  activities  of  several  logical 
devices  (e.g.,  to  track  a  logical  mouse's  cursor  on  a  logical  graphics 
device)  or  implement  more  abstract  virtual  devices  (e.g.,  an  integrated 
videodisc  system). 


4.1  Standard  Interfaces 

Boundaries  between  adjacent  layers  of  the  PORTCO  architecture  are 
called  interfaces.  The  boundary  between  the  application  layer  and  the 
R&C  layer  is  called  the  DSI,  and  the  boundary  between  the  R&C  layer 
and  device  handlers  is  caUed  the  DHL  Each  of  these  interfaces  consists  of 
a  collection  of  services  and  a  set  of  protocols  (or  rules)  for  invoking  them. 
For  example,  one  of  the  services  offered  by  the  DSI  asks  a  logical 
videodisc  to  display  a  still  frame.  Applications  employ  a  packet-passing 
protocol  (using  a  software  interrupt)  to  invoke  this  service. 

DSI  services  are  used  by  applications  and  the  DSI  toolbox  to  control 
logical  devices.  DHI  services  are  used  by  the  R&C  layer  to  load, 
configure,  and  control  device  handlers.  The  DSI  guides  construction  of 
applications  and  application  interfaces,  while  the  DHI  guides 
construction  of  device  handlers. 
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Services  offered  by  the  DSl  and  the  DHI  are  substantiaUy  the  same,  and 
are  defined  by  the  PORTCO  architecture's  device  classes.  When  an 
application  uses  the  DSI  to  manipulate  a  logical  device,  the  R&C  layer 
routes  the  request  to  the  proper  device  handler  through  the  DHL 
Likewise,  when  a  device  handler  alerts  the  R&C  layer  (via  the  DHI)  of 
device  activity,  the  R&C  layer  routes  this  alert  to  the  application  (via  the 
DSI). 

The  DSI  and  DHI  are  not  identical.  Protocols  used  by  each  interface  to 
invoke  services  differ,  and  each  interface  contains  a  unique  set  of 
initialization  and  configuration  services.  References  1  and  2  detail  the 
protocols  and  services  used  by  each  interface. 

The  DSI  toolbox  and  application  software  also  share  a  boimdary,  as 
shown  in  figure  1.  This  means  that  the  toolbox  can  offer  its  own  interface 
to  applications.  This  interface  may  range  from  an  informal  set  of  function 
calls  produced  by  a  particular  vendor  for  its  own  use,  to  a  standard  like 
the  Interactive  Video  Industry  Association's  (LVIA's)  Application 
Interface.  In  either  case,  all  software  in  the  toolbox  employs  the  DSI  to 
communicate  with  peripheral  devices,  and  is  thus  portable  to  any  other 
PORTCO<ompliant  system.  For  example,  implementing  the  IVIA's 
Application  Interface  as  a  DSI  toolbox  component  makes  this  standard 
immediately  available  on  all  PORTCOcompliant  systems. 


4.2  Packets 


Adjacent  layers  in  the  PORTCO  architecture  communicate  using 
contiguous  blocks  of  data  called  packets.  Two  types  of  packets  are  used: 
request  packets,  to  solicit  services,  and  alert  packets,  to  announce  device 
activity. 

Figure  5  illustrates  each  type  of  packet.  As  this  figure  suggests,  each 
request  packet  identifies  one  or  more  services  and  a  logical  device  that 
should  perform  them.  Each  alert  packet  identifies  one  or  more  activities 
completed  asynchronously  by  a  logical  device.  Logical  devices  are 
described  by  their  device  class  and  device  number,  and  services  are 
specified  using  a  service  number  and  various  parametric  data. 
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Figure  5:  Request 


Atoft 

Pacfc«i 


packets 
communiatte  one  or 
more  service 
requests:  alert 
packets  report 
asynchronous 
device  activity. 


As  UlustFated  in  figure  4  (page  8),  packets  are  passed  between  the 
application  layer  and  the  R&C  layer  using  a  software  interrupt,  and 
between  the  R4cC  layer  and  device  handlers  using  an  assembly  language 
call.  Details  concerning  inter-layer  communication  and  packet  formats 
appear  in  references  1  and  2. 


4.3  Confoimance 


Conformance  to  the  PORTCO  architecture  implies  use  of  the  DSI  and  the 
DHL  Applications  and  toolbox  components  conform  by  using  the  DSL 
R&C-layer  software  conforms  by  implementing  the  DSI  using  the  DHL 
Device  handlers  conform  by  implementing  a  single  device  class  in  the 
DHL 

Applications  and  toolbox  components  that  use  the  DHI  directly  do  not 
conform. 
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5.  Further  Reading 


Application  authors,  system  admiiustrators,  and  readers  intending  to 
build  R&C-layer  software  should  study  reference  1,  "The  MS-DOS  Device 
Services  Interface."  This  document  describes  each  DSI  service  in  detail, 
and  specifies  each  service’s  packet  format  and  invocation  protocol.  It  also 
designates  core  and  extendi  services,  and  describes  the  DSI's 
initialization  and  configvuation  services. 

Device  handler  and  R&C-layer  developers  should  review  reference  2, 

"The  MS-DOS  Device  Handler  Interface."  This  document  describes  all 
DHI  services  and  their  invocation  protocols.  It  also  discusses  the  R&C 
layer's  role  in  loading  and  initializing  device  handlers,  and  it  provides 
detailed  constraints  for  developing  compliant  handlers. 

R&C-layer  and  device-handler  developers  should  also  review  references  3 
and  4,  "MS-DOS  Routing  and  Configuration  Layer  Program  Design 
Document"  and  "Guidelines  for  Implementing  MS-DOS  PORTCO  Device 
Handlers."  These  documents  present  detailed  examples  of  software  that 
implements  the  PORTCO  architecture. 
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The  following  list  defines  terms  used  in  this  paper.  These  terms  are 
defined  in  the  context  of  their  use  in  this  paper  and  the  other  documents 
listed  in  section  7.  The  definitions  may  therefore  be  more  restrictive  than, 
or  otherwise  differ  from,  the  commonly  accepted  definitions.  Words  that 
are  italicized  in  definitions  are  themselves  defined  elsewhere  in  this  list. 


Alert 


Alert  packet 

Application 
Application  layer 

Application 

software 

Architecture 

Authoring 

system 

Core  service 

Courseware 

Device  class 


A  service  in  the  DSI  that  interrupts  an 
application  when  a  specific  peripheral  device 
activity  occius.  A  service  in  the  DHl  that 
interrupts  the  R&C  Layer  when  a  specific 
peripheral  device  activity  occurs. 

A  packet  used  to  communicate  an  alert  between 
layers  of  the  PORTCO  architecture. 

Application  software. 

The  highest  partition  in  the  PORTCO 
architecture.  Contains  the  DSI  toolbox. 

Any  software  that  is  part  of  the  application  layer. 


The  organization  or  structure  of  a  system  or  of  a 
system  component. 

Software  that  aids  the  development  of 
computer-based  instruction. 

A  service  within  a  device  class  that  must  be 
provided  by  every  compliant  device  handler  in 
the  class. 

Software  and/or  data  used  to  present 
computer-based  instruction. 

A  collection  of  services  provided  by  a  single 
logical  device. 

A  sofhvare  module  that  implements  the  DHI  for  a 
single  device  class.  Translates  requests  for 
service  from  a  logical  device  into  instructions 
that  a  physical  peripheral  can  understand. 


Device  handler 


Device  handler  The  lowest  layer  of  the  PORTCO  architecture. 
layer  Contains  device  handlers. 

Device  Handler  A  standard  collection  of  services  and  protocols 

Interface  (DHl)  that  defines  the  boundary  between  the  R&C 

layer  and  the  device  handler  layer. 

Device  Services  A  standard  collection  of  services  and  protocols 

Interface  (DSD  that  defines  the  boimdary  between  the 

application  layer  and  the  R&C  layer. 

DSI  toolbox  A  software  module  (or  modules)  providing  an 

interface  between  the  application  software  and  the 
R6rC  layer. 

Extended  service  A  service  within  a  device  class  that  may  be 

provided  by  compliant  demce  handlers  in  the 
class. 

Integrated  system  A  collection  of  computer  hardware  and 

software  sold  as  a  single  unit  by  a  system 
integrator. 

Interface  A  softioare  interface. 

Layer  A  group  of  related  functions  that  make  up  one 
level  of  a  layered  architecture. 

Layered  A  softioare  architecture  in  which  components  are 
architecture  grouped  in  a  hierarchical  arrangement  in  such  a 
way  that  each  layer  provides  functions  and 
services  to  adjacent  layers. 

Logical  device  A  conceptual  device  synthesized  by  using 
characteristics  of  several  similar  peripherals. 
Specified  by  a  device  class. 

Packet  A  contiguous  block  of  data  used  to 

communicate  information  between  layers  of  the 
PORTCO  architecture. 

Peripheral  device  Any  physical  device  that  is  distinct  from  a 

computer’s  main  processor. 

Physical  device  A  computer  system  hardware  component. 
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Portability 


The  ability  of  applications  to  run  correctly  on 
various  system  configurations. 


PORTCO  A  layered  architecture  presenting  a  standard 
architecture  interface  between  peripheral  devices  and 
applications. 

Protocol  A  set  of  rules  governing  the  communication 
between  two  software  modules. 

R&C  layer  Routing  and  configuration  layer. 

Request  A  service  in  the  DSI  or  the  DHI  that  demands 
action  from  a  peripheral. 

Request  packet  A  packet  used  to  communicate  a  request  between 

layers  of  the  PORTCO  architecture. 

Routing  and  The  middle  partition  of  the  PORTCO 

configuration  architecture. 

layer 

Software  The  boundary  between  two  or  more  software 

interface  modules,  or  a  protocol  that  defines  how  two 

software  modules  communicate. 

Software  module  A  named  collection  of  software  instructions  and 

data. 

System  The  number  and  types  of  peripheral  devices 

configuration  connected  to  a  computer. 

System  integrator  A  vendor  that  assembles  and  sells  an  integrated 

system. 

TSR  program  An  MS-EXDS  terminate-and-stay-resident 

program. 
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